INTERNET - DRAFT Diameter EAP

The Extensible Authentication Protocol (EAP) provides a standard mechanism for support of various authentication methods. This document defines the Command-Codes and AVPs necessary for a Diameter Hiller & Zorn [Page 1] INTERNET-DRAFT Diameter EAP Application June 2002 node to support the PPP Extensible Authentication Protocol (EAP). 1. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 2. Extensible Authentication Protocol Support in Diameter The Extensible Authentication Protocol (EAP) [RFC2284] provides a standard mechanism for support of various authentication methods. Through the use of EAP, support for a number of authentication schemes may be added, including smart and token cards, Kerberos [RFC1510], public-key, one-time passwords [RFC1938], and others. This document describes the Command-Code values and AVPs that are required for an EAP packet to be encapsulated within the Diameter protocol. Since authentication occurs between the EAP client and its home Diameter server, end-to-end authentication is achieved, reducing the possibility for fraudulent authentication, such as replay and man-in-the-middle attacks. End-to-end authentication also provides for mutual (bi-directional) authentication, which is not possible with PAP and CHAP in a roaming PPP environment. 2.1. Protocol Overview The EAP conversation between the authenticating peer and the access device begins with the initiation of EAP within a link layer, such as PPP [STD51] or IEEE 802.1x [IEEE802.1x]. Once EAP has been initiated, the access device will typically send to the Diameter server a Diameter-EAP-Request message with a NULL EAP-Payload AVP, signifying an EAP-Start. The Port number and the identity of the access device (e.g. Origin-Host or NAS-Identifier) MUST be included in the Diameter-EAP-Request message. If the Diameter home server supports EAP, it MUST respond with a Diameter-EAP-Answer message containing an EAP-Payload AVP that includes an encapsulated EAP packet [RFC2284], and the Result-Code AVP set to DIAMETER_MULTI_ROUND_AUTH, signifying that a subsequent request is expected. The EAP payload is forwarded by the access device to the EAP client. The initial Diameter-EAP-Answer in a multi-round exchange normally includes an EAP-Request/Identity, requesting the EAP client to Hiller & Zorn [Page 2] INTERNET-DRAFT Diameter EAP Application June 2002 identify itself. Upon receipt of the EAP client’s EAP-Response [RFC2284], the access device will then issue a second Diameter-EAPRequest message, with the client’s EAP payload encapsulated within the EAP-Payload AVP. A preferred approach is for the access device to issue the EAPRequest/Identity message to the EAP client, and forward the EAPResponse/Identity packet, encapsulated within the EAP-Payload AVP, as a Diameter-EAP-Request to the Diameter server. This alternative reduces the number of Diameter message round trips, and is compatible with roaming environments, since the Destination-Realm is needed by Diameter agents for routing purposes. Note that this alternative cannot be universally employed, as there are circumstances where a user’s identity is not needed (such as when authorization occurs based on a calling or called phone number). The conversation continues until the Diameter server sends a Diameter-EAP-Answer with a Result-Code AVP indicating success or failure, and an optional EAP-Payload. The Result-Code AVP is used by the access device to determine whether service is to be provided to the EAP client. The access device MUST NOT rely on the contents of the optional EAP-Payload to determine whether service is to be provided. A Diameter-EAP-Answer message containing an EAP-Payload of type EAPSuccess or EAP-Failure MUST NOT have the Result-Code AVP set to DIAMETER_MULTI_ROUND_AUTH. If authorization was requested, a Diameter-EAP-Answer signifying successful authentication MUST also include the appropriate authorization AVPs required for the service requested (see sections 4 and 7). Diameter-EAP-Answer messages whose Result-Code AVP is set to DIAMETER_MULTI_ROUND_AUTH MAY include authorization AVPs. Unless the access device interprets the EAP-Response/Identity packet returned by the authenticating peer, it will not have access to the user’s identity. Therefore, the Diameter Server SHOULD return the user’s identity by inserting it in the User-Name attribute of subsequent Diameter-EAP-Answer packets. Without the user’s identity, the Session-Id AVP MAY be used for accounting and billing, however operationally this MAY be very difficult to manage. A home Diameter server MAY request EAP re-authentication by issuing the Re-Auth-Request [BASE] message to the Diameter client. Should an EAP authentication session be interrupted due to a home server failure, the session MAY be directed to an alternate server, but the authentication session will have to be restarted from the Hiller & Zorn [Page 3] INTERNET-DRAFT Diameter EAP Application June 2002